WebOrion® Blog / Security Articles / Best Practices to Address Web Defacements

Best Practices to Address Web Defacements

Web defacement is one of the biggest security challenges to any organization that is running online. Web defacement is typically done by hackers who break into a web server and replace the hosted website with one of their own, using techniques such as phishing, code injection, cross site scripting etc. Common targets of defacement are religious websites, govern­ment websites, bank websites and corporate websites.

 

There are no software or hardware solutions that guaranties 100% safety against web defacement, but there are best practices that can prevent or mitigate the problem of web defacement.

Here are some best practices that address the issue of web defacements:

1. Security audits and penetration testing

The hackers are always trying to exploit vulnerabilities that are not patched properly. This is one of the known vulnerabilities: use of open ports to connect to the server without logging on, execute malicious code over an open legitimate connection, using a buffer overflow to import malicious code that executes in the security context of the system on the server. Regular audit and penetration testing are helpful in evaluating the security of an IT infrastructure (operating systems, service and application flaws, improper configurations, or risky end-user behavior) and better protecting the system.

2. Defend yourself against SQL injection attacks

SQL injection attacks involve the use of SQL statements inserted into data entry fields in order to affect the execution of predefined SQL statements. With the modified SQL statements, attackers may be able to tamper with existing data, destroy data in the system, or even extract the entire database of the system.

Many web applications take user input from a form, and the user’s input is put directly into the SQL statement within the Web application. The following is a negative example whereby the attacker can easily enter an “email” that leads to an SQL injection attack:

$result = $mysqli->query(‘SELECT email, userid FROM members WHERE email = “‘.$email.’”)’;

You can easily prevent this by using bound variables with prepared statement method; most libraries allow you to bind inputs to variables inside a SQL statement, like in this PHP example.

$stmt = $mysqli->prepare(“SELECT email, userid FROM members WHERE email = ?;”);
$stmt->bind_param(“s”, $email);
$stmt->execute();

This method works because the parameter values are combined with the compiled statement, not a SQL string. By specifying parameters (using ?) you tell the database engine what to filter on.

But the best method of preventing SQL injection is to avoid the use of dynamically generated SQL in your code. Instead, use stored or canned procedures.

In addition, where possible, validate input. For example:

 

  • Limiting input only to accepted characters: e.g. Letters in a number field?
  • Whitelisting: e.g. /[a-zA-Z0-9]{0,20}/, the set of possible values (if there is one)
  • Length checks: e.g. 10 digits for 4 digit year field?

 

3. Defend yourself against Cross-Site Scripting (XSS) attacks

Cross-site scripting (XSS) is when an attacker tries to pass scripting code into a web form to attempt to run unauthorized code on the website. It allows attackers to embed scripting code in the webpage that can perform a variety of unauthorized actions including: changing the appearance of the webpage, stealing session cookies of other users of the website or even as a means to form XSS attacks on other websites.

To prevent XSS attacks, you have to prevent the user from injecting code through web forms.

One of the best practices to prevent cross site scripting attacks is to ensure both your inputs and outputs are sanitized. This helps to prevent both reflected XSS (i.e. scripts that are reflected from an unsanitized input) and stored XSS (i.e. scripts that may be stored in a database, and reflected through an unsanitized output).

One way would be to perform URL encoding to replace all potentially malicious characters (e.g. <script> tags) with their actual URL-encoded substitutes (i.e. &lt;script&gt;), which will ensure that HTML cannot be arbitrarily injected into your page. Alternatively, you may use libraries such as HTML Purifier, which uses a whitelist strategy to allow only certain HTML tags.

One well known use case for arbitrarily injecting client-side scripts into a page is to perform session hijacking attacks. A malicious script can be crafted to make the visitor’s browser to silently send all cookies back to the attacker, which can result in the attacker being able to assume the credentials of all these users! A good practice against this attack is to use HTTP-Only Cookies. With this, cookies sent over HTTP cannot be accessed by Javascript via document.cookie, thus preventing cookie theft via XSS.

On the other hand, another good layer of defence is to use Web Application Firewalls (WAF). WAFs are able to inspect all incoming requests for malicious input values, filter out malicious output and block suspicious requests on the whole.

4. Use defacement monitoring and detection tools

The effects of web attacks are leaving companies with a short time to react and perform damage control after an incident. Defacement monitoring and detection tools are one of the best solutions to monitor any defacement or unauthorized integrity change in the websites. These are some of the most used monitoring and detection tools: Banff Cyber’s WebOrion Defacement Monitor, Site24x7 and Nagios. Careful evaluation and configuration of the tools to detect both full and partial defacements involving HTML as well as linked images, scripts and stylesheets are important to ensure an effective tool is in place.

5. Prepare to respond to defacement incidents

What do we do when our website is defaced? A good detection tool only tells you when your website is defaced but not the action that is to be taken. It is therefore important to put in place a set of incident response procedures, and ensure that you have the right personnel to respond to a web defacement. The technical response team will likely involve the security manager, web masters/web developers and the web server team. It may also be important to have corporate communications prepare a public message to preserve the web reputation of the company.

To be secure, the web server that had been defaced should be taken offline for detailed investigation and forensics. The hacker might have penetrated deeper into the organization to access application servers, databases, etc.

In addition, companies can either prepare a maintenance page or consider Banff Cyber’s WebOrion Restorer. The Restorer is able to create a secured replica of the website that does not contain similar vulnerabilities to the defaced server. The restorer allows continued web presence for the organization while the main web server is being looked at. In short, make an action plan for handling the restoration process that will shorten the time for recovery. If web defacement happens, the WebOrion Restorer will assist with the recovery, reducing the loss of data, time and money for the organisation.

Conclusion

Website defacement can result in damage to a site’s reputation, loss of valuable information and user privacy, loss of money and loss of time. Hence it needs to be prevented before it happens.

In addition, prepare a backup copy that can be used in the event that a defacement occurs, and enrol the help of a monitoring service from companies that have expertise in the area, so that a defacement can be detected and restored quickly to reduce any incurred losses.

Thank you, your form has sent successfully